QRZ! Ham Radio 3/QRZ Ham Radio Callsign Database - Volume 3.iso/digests/tcp/930327.txt

Internet Message Format | 1994-06-04 | 16KB

Date: Sun, 19 Dec 93 04:30:01 PST
From: Advanced Amateur Radio Networking Group <[e-mail]>
Errors-To: [e-mail]
Reply-To: [e-mail]
Precedence: Bulk
Subject: TCP-Group Digest V93 #327
To: tcp-group-digest


TCP-Group Digest            Sun, 19 Dec 93       Volume 93 : Issue  327

Today's Topics:
           Borland C++ 4.0 sequential decoding performance?
                             Ham Networks
               Some thoughts on Packet Radio Netwoking

Send Replies or notes for publication to: <[e-mail]>.
Subscription requests to <[e-mail]>.
Problems you can't solve otherwise to [e-mail].

Archives of past issues of the TCP-Group Digest are available
(by FTP only) from UCSD.Edu in directory "mailarchives".

We trust that readers are intelligent enough to realize that all text
herein consists of personal comments and does not represent the official
policies or positions of any party.  Your mileage may vary.  So there.
----------------------------------------------------------------------

Date: Sat, 18 Dec 93 17:25:26 -0800
From: Phil Karn <[e-mail]>
Subject: Borland C++ 4.0 sequential decoding performance?
To: [e-mail]

Who has a copy of Borland C++ 4.0? I'd like to see if its significantly
faster than 3.1 before I buy it, otherwise I think I'll look seriously
at the GCC port.

I have recently been playing with a Fano decoder in C. (This is one of
the standard sequential decoding algorithms for convolutional codes
with constraint lengths too long for viterbi decoding). When I compile
it with Borland C++ 3.1 and run it on my 486-50 DOS machine, it runs
at about 228,000 branches/sec. When I compile and run the very same
code on my 486-DX2 386BSD machine with GCC, I get 573,000
branches/sec, about 2.5x faster. Full speed optimization was requested
from both compilers.

Only 1.32x of the speedup can be accounted for by the faster CPU (and
it's not even a "true" 66 Mhz system - it has 33 Mhz external cache,
while the DOS system has 50 Mhz external cache). I attribute the other
1.9x to the better compiler, although some of it is probably due to
Borland C having to emit override prefixes for the many 32-bit
operations in my code. (In the 486 protected mode that BSD uses, the
instructions assume 32-bit operations by default).

By the way, these speed figures, even under DOS, are more than enough
to handle a 56kb/s packet modem in real time at fairly high error
rates.  A sequential decoder given perfect data searches only 1
branch/bit, so under DOS this decoder can decode 228 kilobits/sec (456
kilosymbols/sec assuming a rate 1/2 code). As the channel symbol error
rate increases, the number of branches searched per decoded bit rises,
slowly at first and then very rapidly as decoding bogs down. Again,
these figures assume a rate 1/2 code:

Channel symbol error rate average branches/bit
.00    1
.01 (1%)   1.2
.02 (2%)   1.5
.03    1.8
.04    4-5
.06    6-10, sometimes many more

These are approximations; the real numbers are random variables, and
can on occasion be much higher. But since this is a packet system, you
can always ask for a retransmission if decoding takes too long.

So who has a 486 and Borland C++ 4.0, and would be willing to try my
code to give me a few benchmark results?

Phil

------------------------------

Date: Sat, 18 Dec 1993 11:45:58 -0700 (MST)
From: William Ti Baggett <[e-mail]>
Subject: Ham Networks
To: Advanced Amateur Radio Networking Group <[e-mail]>

> Date: Fri, 17 Dec 93 15:45:11 MDT
> From: "Karl Larsen" <[e-mail]>
> Subject: Ham Networks
> To: [e-mail]
>
>      I have 3 frequencies at my home and all radios are connected
> to tnc's that in turn are connected to my g8bpq switch. The
> frequencies are 145.07, 223.4, 445.1 MHz. All 3 radio's can
> transmitt without effecting another radio's reception. And all
> three networks end here (there are no hidden xmitters). The 445.1

Karl, Isn't ELP96 (WA5PIE-2) and #ELPNE (N5RG-3) on the east side of El
Paso a hidden transmitter to you station? We're both at about 4000 feet
ASL seperated by the Franklin and Organ Mountains which is 7000 feet+.

Besides, even if you do not have mountains but some really good tower
sights on a flat area (like Kansas), the second hop away from your node is
going to be a hidden transmitter. Almost always:

      Backbone node #1 ----------- Backbone node #2 ---------Backbone node #3

Node 1 and Node 3 are hidden transmitters. If they weren't then, why the
heck is Node 2 in there any way?

Hence the fact that there must be frequency switching every hop along the
way on a backbone. ONLY if you REALLY want to get rid of hidden transmitters.

But that costs a lot I will admit.

>      So the message is clear. You can improve a great deal over
> the norm by making a 1200 baud network actually work at 1200 baud!
> And don't think getting a 9600 baud network up and running is
> simple. There are no cook-books and the problems are many and
> frustrating.

Data rate and through put are different things...usually VERY different
especially around here... Through put << Data rate

OK, Maybe I'm still freaked out from a finals week from hell. But after
reading all the stuff on here for the last few weeks, I've seen mostly a
lot of BS about this works (sort of) so why should we change it.

(BTW Running IP over NET/ROM is _stupid_ although it needs to be done
sometimes. So why not FIX the PROBLEM and implement THENET X1J nodes that
take care of both protocols as they should be taken care of...but thats
another message for January)

Well, this is amateur radio and we are not to be satisfied with FTPing a
file at 9600, 19.2K bps, or even 56K bps. I want my 100 Mega bps! Is it
unrealistic? NO! Is it unlikely? Yes, right now it is. But if we do not
get together and quit hashing one protocol, datagram vs. VC (which I
personally do not feel we really have any direct implementation of), etc
then we'll never get anywhere.

Flame on. I'm leaving for a month to forget about all the gateway stuff.
When I get back I should be ready to start building the gateway RF
network.

73 & Merry Christmas to all
Tim, AA5DF NMSUGW Gateway dude

 I live for Twisted Pair Packet!

 Amateur Packet Radio thru-put on 145.01: 24 Mega bits per fortnight

  Support NAFTA! National Association of Fourier Transform Addicts!
********************************************************************
Tim Baggett, AA5DF                    Electrical Engineering Student
                                      New Mexico State University
Internet: [e-mail]
AMPR: [e-mail]           US Snail: 1970 Buchanan Avenue
(When on) AA5DF.AMPR.ORG                        Las Cruces, NM 88001
********************************************************************

------------------------------

Date: Sat, 18 Dec 93 21:04:11 mdt
From: [e-mail]
Subject: Some thoughts on Packet Radio Netwoking
To: [e-mail]

Some thoughts on packet-radio networking:

Approximately a year ago, the task to rebuild and update the Utah
Packet network was undertaken by the UPRA, the Utah Packet Radio
Association.  In that time, there have been quite a few
discussions concerning networking, network users/designers in
other parts of the country (and world) have been asked about THEIR
networks, and we have also did some original thinking on our own.

Almost immediately it was realized that there are a lot of
band-aid solutions, non-solutions, and even a few genuine
solutions.  We also ran into several simple truths based on our
research and observations, research, and communications with
others.

Firstly, anyone who directly applies wireline computer networking
to RADIO links ought to be shot!  Very simply put, the protocols
we are using now are simply NOT designed be used in the way we use
them!  In computer networks, there are generally no "hidden
terminals" or "hidden nodes" (or whatever you want to call
them...)  Any situation where this arises blows to hell the
collision avoidance mechanisms built into the protocols that we
use since there is NO way one can arbitrate a simplex channel
(under current protocols) where there are hidden terminals.

Most of the congestion, it could be argued, occurs at the
user-interface level on some 1200 baud channel.  There is the
tendancy to "put up another node" to "help" things out.  Too
often that "other node" is stuck on the same frequency as the
congestion problem.  Worse, that other site often effectively
increases the geographic coverage of that channel thereby
increasing the number of users of that channel, not to mention the
number of hidden terminals.  Putting up a packet repeater can
reduce the number of hidden terminals tremendously (assuming that
everyone has their parameters set somewhat correctly...  but
that's another problem altogether...) but keep in mind that even
if you ARE the ONLY one on the channel, 1200 baud is STILL pretty
darn slow!

Here in Utah, we have taken the "divide-and-conquer" approach.
With this area being fairly mountainous, we have decided to do
what we can to put the geography and topography to work.  The Salt
Lake City area lies in a valley surrounded on all sides by
mountains, with the exception of the gap to the north (where that
big lake is...) and some large population centers to the north and
south.  The paths to these northern and southern population
centers are, for the most part, unreliable since there are some
low mountain ranges in the way.  This is how the network was
designed:

1) The local area was geographically divided into 3 pieces:  Salt
Lake Metro, Utah County to the south and Davis/Weber (pronounced
"weebur" as in "WeberSat") to the north.  Within each of those
areas almost anyone who has a half-decent station set up can be
heard throughout the entire area.

2) Each are is given its OWN set of SIMPLEX frequencies  For
example, the Salt Lake area has THREE 1200 baud frequencies, Utah
county has TWO, the Davis/Weber county area has 3, etc.   Since it
is possible for there to be some marginal paths between all of
these areas, all frequencies are different.  This allows a user
to seek out a less-congested frequency in his/her own area.

3) All of these frequencies are tied together via a 70cm 9600 baud
simplex channel.  Because we are "geographically blessed" one
can strategically arrange it so that ALL sites of the 2 meter
1200 baud "local" frequencies are visible to each other.  In that
way the "intertie" channel can operate free of hidden terminals.

4) Users are encouraged to use ONLY those frequencies intended for
their local area.  There are various ways to "encourage" proper
use and these include:  location selection, using directional
antennas at the node sites, publicizing the "correct way" to use
the network and others.  In order for this to work the users must
be aware that if, for instance, they wish to access, say, a Davis
county station from Salt Lake it is better that they get on the
Salt Lake channel rather than sneak over to the Davis county
channel and try to do it there.  More than that, the network must
be designed so that the user can do just that!

You may ask "Why not just put up a 1200 baud repeater?"  The
answer is simple:  You just DO NOT set up a repeater at a slow
data rate for the intent of serving a large number of people.  For
the price of a single repeater, you can set up several smaller
simplex network and tie them together.  Then, the users in those
smaller networks aren't competing with EVERYONE else!  This is not
to say that a repeater has no place.

5) A 9600 baud repeater is being established for serving those
parts of the network that can't reasonably be served by simplex
channels without becoming hidden terminals.  The repeater is open
for use by all, but if you CAN access a local frequency without
harming it, you are strongly encouraged to do so instead.

As far as repeaters go, they are best used for tying large areas
together that could not be tied together by other reasonable
means.  For example, if we need to provide coverage to a large
rural area, a repeater might be an option.  However, one gets more
"bang for the buck" by putting up a 9600 baud repeater and then
linking 1200 baud channels through it.  Repeaters also have a
definite disadvantage over simplex channels, though:  They can go
down!  The implicit redundancy in a simplex-based network is
invaluable in an emergency!

On a smaller scale (because of fewer users at present) those
strategies used on 2 meters are being applied at 9600 baud for
9600 baud uses.  Of course, the interconnections between the 9600
baud channels will be done at a rate much higher than 9600 baud.

It is extremely important to note that these approaches are
designed for our local topography and we have used that to our
advantage.  Any other area would have to base their system on
their specific needs and realities.


In the meetings and discussions a somewhat unfortunate truth has
been observed:  It is hazardous to talk about networking in the
presense of those who are unfamiliar with its basic truths.  Case
in point:  Many networking people will tell you about arguments
that they have gotten into when they uttered "Users will not be
allowed on the backbone..."  While this is absolutely true (for a
network to function you CANNOT allow DIRECT user access to the
backbone...  you WILL introduce hidden-terminal problems) the
end-user will most certainly benefit from the use of the backbone.
Too often this sort of statement has resulted in a
misunderstanding that resulted in either a network delayed in its
construction or, even worse, the construction of a BAD network!

One more thing:  If you are thinking about putting up a network,
do EVERYTHING you can to avoid putting up a "single-frequency"
network.  The debacle on 145.01 is a classic example of this:
True, if there are a LOT of stations spread out over a large area
on 145.01, you DO have a lot of geographical coverage.  You *CAN*
connect across the entire network and go anywhere on it...  as
long as no-one uses it, that is!!!  The instant you try to achieve
throughput (especially from different directions!) the possible
throughput goes down exponentially!  The result of this is
retries, backoff delays, and perhaps worst of all, people giving
up!  In a case such as this, simply going to a higher baud rate
will NOT solve the problem:  It is simply a band-aid solution that
will seem to mask the problem for only a short time.

Finally, it should be noted that these are first steps in the
upgrading of the network around the state.  The infractruction is
being put into place to provide for user and network access at
speed of 9600, 56 kbaud, and higher.  Access at these speeds
changes the entire face of amateur packet radio...

Much of this is IMHO and I would welcome any comments or
questions about any of it.

<Clint>
[e-mail]   Amprnet
[e-mail]       Internet
ka7oei@wb7esh                   MSYS


P.S. Not 'infractruction' but 'infrastructure'... :-)

------------------------------

End of TCP-Group Digest V93 #327
******************************
******************************